High speed packet access evolution (HSPA+) herein refers to the Third Generation Partnership Project (3GPP) radio-access technology evolutionary enhancement of high speed downlink packet access (HSDPA) and high speed uplink packet access (HSUPA) standards used in Universal Mobile Telecommunications Systems (UMTS) wireless communications systems. Some of the improvements to HSDPA (3GPP UMTS Standard Release 5) and HSUPA (3GPP UMTS Standard Release 6) proposed as part of HSPA+ include higher data rates, higher system capacity and coverage, enhanced support for packet services, reduced latency, reduced operator costs, and backward compatibility with 3GPP legacy systems. Herein, 3GPP legacy systems generally refer to any one or more of the pre-existing 3GPP standards from Release 6 and earlier. Achieving these improvements involves the evolution of both the radio interface protocol and network architecture.
The following list includes relevant abbreviations:                3GPP—Third Generation Partnership Project        AM—Acknowledged Mode        AMD—Acknowledged Mode Data        ARQ—Automatic Repeat Request        CN—Core Network        CP—Control Plane        CS—Circuit Switched        DL—Downlink        HARQ—Hybrid Automatic Repeat Request        HSDPA—High Speed Downlink Packet Access        HSUPA—High Speed Uplink Packet Access        IP—Internet Protocol        LCID—Logical Channel Identifier        LTE—Long Term Evolution        MAC—Medium Access Control        PDCP—Packet Data Convergence Protocol        PDU—Packet Data Unit        PHY—Physical        PS—Packet Switched        QoS—Quality of Service        RAN—Radio Access Network        RLC—Radio Link Control        RNC—Radio Network Controller        CRNC—Controlling RNC        SRNC—Serving RNC        RNS—Radio Network Subsystem        RoHC—Robust Header Compression        RRC—Radio Resource Control        RRM—Radio Resource Management        Rx—Reception/Receiving        SAP—Service Access Point        SDU—Service Data Unit        SN—Sequence Number        TB—Transport Block        TBS—Transport Block Set        TF—Transport Format        TFC—Transport Format Combination        TFRC—Transport Format Resource Combination        TM—Transparent Mode        TM—Transparent Mode Data        Tx—Transmission/Transmitting        UE—User Equipment        UL—Uplink        UM—Unacknowledged Mode        UMD—Unacknowledged Mode Data        UP—User Plane        UMTS—Universal Mobile Telecommunications System        UTRAN—Universal Terrestrial Radio Access Network        WTRU—Wireless Transmit/Receive Unit        
The Layer 2 radio interface protocols include medium access control (MAC) and radio link control (RLC) protocols. Some of the functions of the MAC and RLC protocols are discussed hereinafter, however, other functions that are not discussed are assumed to function as described in 3GPP standards.
Some of the main functions of the MAC protocol are:                Channel mapping of MAC packet data units (PDUs) to physical channels        Multiplexing of higher layer data into packet data units (PDUs)        Quality of Service (QoS) that takes into account data priority for scheduling and rate control        Link adaptation for QoS and multiplexing        Hybrid automatic repeat request (HARQ) for control of fast retransmissions for error correction        
The MAC layer multiplexes higher layer data into MAC PDUs. The MAC PDUs that are sent to the physical (PHY) layer are called transport blocks (TBs). A set of TBs, referred to as a transport block set (TBS), are sent every transport time interval (TTI) to the PHY layer with a corresponding Transport Format (TF) that describes the physical layer attributes for that TBS. If the TBS is derived from combining or multiplexing data from more than one logical RLC channel, then a combination of TFs known as transport format combination (TFC) is used. As part of link adaptation, the MAC layer performs the TFC selection based on RLC logical channel priority, RLC buffer occupancy, physical channel conditions, and logical channel multiplexing. The reference to MAC TFC selection here is generic and may include, for example, transport format resource combination (TFRC) selection in the high speed MAC (MAC-hs) protocol in HSDPA.
The RLC protocol in Layer 2 has a big impact on the latency and throughput of data. The RLC protocol in 3GPP legacy systems, including Release 6 and earlier, is physically located in the radio network controller (RNC) node.
Some of the main functions of the transmitting (Tx) RLC protocol that occur in the Tx RLC entity are:                Macro-diversity to enable a UE to be connected simultaneously to two or more cells and receive data (optional)        Segmentation of higher layer radio bearers        Concatenation of higher layer radio bearers        Error detection and recovery of PDUs received in error        HARQ Assisted ARQ for fast retransmissions of PDUs received in error        
Some of the main functions of the receiving (Rx) RLC protocol that occur in the Rx RLC entity are:                Duplicate PDU detection        In sequence PDU delivery        Error detection and recovery of PDUs received in error        HARQ Assisted ARQ for fast retransmission of PDUs received in error        Reassembly of higher layer data from received PDUs        
Three modes of operation for the RLC layer are acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM). In AM operation, which includes the transmission of some higher layer user plane data, the RLC protocol is bi-directional, such that status and control information is sent from Rx RLC entity to Tx RLC entity. In TM and UM operation, which includes the transmission of some control plane radio resource control (RRC) signaling data, the RLC protocol is unidirectional, such that the Tx RLC entity and Rx RLC entity are independent with no status and control information exchanged. Also, some of the functions such as HARQ assisted ARQ and error detection and recovery are typically used only in AM operation.
The RLC PDU sizes are determined by the RRC layer based on the long term quality of service (QoS) requirements of the application data carried by the RLC logical channels. According to 3GPP legacy systems, including Release 6 and earlier, the RLC layer is configured on a semi-static basis by the RRC layer with predetermined RLC PDU sizes. Thus, the RLC PDU size is fixed on a semi-static basis by upper layers and sequence numbers (SNs) are assigned to the RLC PDUs. AM data RLC PDUs are numbered by modulo integer sequence numbers (SNs) cycling through the field 0 to 4095.
The RLC PDU types are DATA, CONTROL and STATUS. The DATA PDU is used to transfer user data, piggybacked STATUS information and the polling bit when RLC is operating in AM, where the polling bit is used to request a status report from the receiver. The CONTROL PDU is used for RLC RESET and RESET acknowledgement (ACK) commands. The STATUS PDU is used to exchange status information between two RLC entities operating in AM and can include super-fields (SUFIs) of different types including, for example, the Window Size SUFI and the Move Receiving Window (MRW) SUFI.
A transmission window refers to the group of PDUs that are being processed for transmission or are being transmitted currently. Similarly, the reception window generally refers to the group of PDUs being received or processed at the receiver. The transmission or reception window size typically refers to a number of PDUs that are being transmitted or received, respectively, by the system. The transmission and reception window sizes need to be managed using flow control in order not to overload the system and incur undesirable packet loss rates. Generally speaking, once a PDU has been successfully received at the receiver, a new PDU may be added to the transmission and/or reception window.
An RLC transmission window is composed of a lower bound and an upper bound. The lower bound consists of the SN of the PDU with lowest SN transmitted and the upper bound consists of the SN of the PDU with the highest SN transmitted. The RLC is configured with a maximum transmission window size, such that the maximum number of PDUs transmitted from the lower bound to the upper bound should not exceed the maximum window size. The RLC reception window is similarly configured. The lower bound of the RLC reception window is the SN following that of the last in-sequence PDU received and the upper bound is the SN of the PDU with the highest sequence number received. The reception window also has maximum window size, where the maximum expected PDU SN is equal to the lower bound SN plus the maximum configured window size. The transmission and reception windows are managed using transmission and reception state variables, respectively, as described hereinafter.
Among the techniques for flow control are RNC/Node B flow control, RLC flow control and RLC status reporting. RNC/Node B flow control refers to the procedures to minimize the downlink data buffered in the Node B. Typically, data destined for a UE flows from the Core Network (CN) through a source radio network controller (SRNC) and a Node B, and a drift radio network controller (DRNC) in a drift situation where the UE is handed off to a cell with a different radio network subsystem (RNS). The Node B grants allocation credits to the SRNC, and DRNC under drift, allowing the SRNC to send an equivalent number of PDUs to the Node B, such that the RNC can not send more PDUs until more credits are granted. RLC flow control refers to the managing of packet transfer, including window size, between the Tx RLC entity and the Rx RLC entity. RLC status reporting allows the receiver to report status information to the transmitter when polled by the transmitter.
According to 3GPP standards, various RLC protocol parameters for flow control are signaled by upper layers to the RLC layer, including the following parameters:                Poll_Window        Configured_Tx_Window_Size        Configured_Rx_Window_Size        
These parameters, described in further detail hereinafter, are used by the RLC layer along with various RLC state variables for flow control in order to configure transmission and reception window size. According to 3GPP legacy systems, such RLC state variables depend on SNs. For example, the following RLC transmitter state variables are affected by SNs:                VT(S) is the send state variable containing the SN of the next AM data PDU to be transmitted for the first time        VT(A) is the acknowledge state variable containing the SN following the SN of the last in-sequence acknowledged AMD PDU, and forms the lower edge of the transmission window        VT(MS) is the maximum send state variable containing the SN of the first AM data PDU that can be rejected by the peer receiver        VT(WS) is the transmission window size state variable        
All arithmetic operations on VT(S), VT(A), VT(MS), VR(R), VR(H) and VR(MR) depend on one or more SNs. The following RLC receiver state variables are also affected by SNs:                VR(R) is the receive state variable containing the SN following that of the last in-sequence AM data PDU received        VR(H) is the highest expected state variable containing the SN following the highest SN of any received AM data PDU        VR(MR) is the maximum acceptable receive state variable containing the SN of the first AM data PDU that shall be rejected by the receiver        
In 3GPP legacy systems, many functions needed to support data transfer service, such as RNC/NodeB flow control, RLC flow control and RLC status reporting, are based on SNs or effectively the number of PDUs when the RLC PDU size is fixed. The reason is that transmitting and receiving window size can be accurately characterized using the number of PDUs and the known and fixed PDU size. However, in proposals for HSPA+, the RLC may be configured by the upper layers to allow flexible RLC PDU sizes. If upper layers such as the RRC layer configure a flexible RLC PDU size operation then the RLC PDU size is variable up to a semi-statically specified maximum RLC PDU payload size.
It is recognized herein that existing SN based RLC operations may not function efficiently with flexible RLC PDU size. The reason is that using the number of PDUs to define window size will result in variable window size causing possible buffer overflows in the RNC and buffer underflows in the Node B. Accordingly, it would be beneficial to provide alternate methods for configuring window size for flexible RLC PDU size operations.